[レポート] ARC408: Route 53 SLA 100% の舞台裏 (Under the Hood of Amazon Route 53) #reinvent

AWS re:Invent 2018 にて、11/28 （現地時間）に行われた下記セッションをレポートします。

セッションタイトル

• ARC408 Under the Hood of Amazon Route 53

概要

セッション概要より抄訳：
多くの AWS サービス、さらにいえば多くのインターネットアプリケーション・Webサイトは、DNS として Route 53 を利用しています。このセッションでは、Route 53 を如何に大規模かつ SLA 100% のサービスとして AWS エンジニアリングチームが運営しているか説明します。

The engineering team that worked on Amazon Route 53 discuss its underlying implementation in a talk for developers and system operators of all kinds. We start by sharing insights and lessons learned on how to design, deploy, and operate your own services while meeting extreme demands for scale and availability. Many of the largest AWS services rely on Route 53 for DNS, as do many of the internet's busiest applications and websites. This talk takes you inside Route 53 as we look at how the engineering team runs a highly distributed service at massive scale while maintaining a 100% availability SLA.

Speaker

• Alec Peterson - General Manager, Route 53, AWS
• Gavin McCullagh - System Development Engineer, Route 53, AWS

資料

※ChalkTalk セッションのため録画はありません

内容

A haiku about DNS

DNSじゃない
DNSであるはずがない
DNSだった

※元ネタ（トラブルシューティング川柳）：

Card

Route 53 データプレーンのデザインゴール

• 100% SLA
  • 何故 100% を目指すのか？
  • -> 全ての SLA 99.99% のサービスが DNS に依存 しているから
• 全ての AWS カスタマーをサポート
• 顧客環境の分離
• 低レイテンシ
• 使いやすさ
• DNS キャッシュについて
  • 「300以上のリゾルバが TTL 60秒で動作することを想像してみてください」
  • いくつかのリゾルバは救済機能を持っている
    • プリフェッチ（先読み）
    • ストール時には最後に取得した値を使う
    • ほとんどのリゾルバはそんなことをしてくれない ?
  • Amazon S3, DynamoDB, RDS ... TTL 5秒
  • Amazon Aurora ... TTL 1秒

よくある障害

• この辺りが落ちる：
  • ホスト
  • スイッチ（ネットワークスイッチ）
  • ルータ
  • 電源
  • PoP（接続ポイント）
• 解決策 : 切り離し可能で独立した PoP

※PoP (Points of Presence : エッジロケーションに設置してある物理ホスト群)

まれな障害

• データプレーン全体が落ちる要因
  • デプロイ
  • オペレータが全体的な変更を行った
  • 共用ルーティング・共用トランジット接続

データプレーンの冗長化

• DNS リゾルバ（クライアント）はそれぞれの NS にリトライする
• それぞれのデータプレーン（「ストライプ」）はそれぞれの CIDR /23 サブネットをもち、個別にルーティングされている
• 各ストライプごとに別々に操作しデプロイする

結果として

• ひとつのデータプレーンが失われても、影響を最小化できた
  • PoP ブラックホール
  • ルーティングの問題
  • トランジット接続プロバイダの起こした障害
  • TLD障害

Blast radius reduction

• 「爆発の影響範囲（Blast radius）」の縮小
• Anycast
• 20 ある PoP はそれぞれ BGP の IP prefix をアドバタイズしている
• DNSリゾルバ（クライアント）は、それぞれストライプごとに最も近い PoP へ接続する
• Blast radius を小さくすれば、レイテンシが上昇する
• もし PoP ひとつが落ちたら、別のところへルーティングする

TLD ごとにストライプが分かれている

• 赤 ... .com
• 緑 ... .net
• 青 ... .org
• 黄 ... .co.uk
• 紫 ... その他

結果

• データプレーンの障害は一般的に特定地域 /ストライプ単位に限定できた
• 行儀の悪いクライアントの影響は特定地域に限定
• デプロイ失敗は特定地域 /ストライプ単位
• レイテンシがトレードオフ

顧客環境の分離

• 顧客へのお互いの影響を防ぐ
• トレードオフ
  • 相乗りさせると安く済む
  • 独立させると高く付く
• 「爆発の影響範囲（Blast radius）」

単に水平分散させるだけだとダメ

• 影響範囲 = いち顧客

シャーディング（シャッフルシャーディング）

• 1顧客を複数のシャードに割り当てておけば、ひとつ落ちても大丈夫
• Route 53 はストライプごとに 512 サーバ
• 全ての Hosted Zone は、各ストライプにひとつ NS を持っている
• オーバーラップ(相乗り)は 2サーバまで

ルーティング層としての Route 53

• 顧客ごとにひとつの DNS 名
• 物理的なエンドポイントごとにひとつの A / AAAA レコード
• ヘルスチェック
• 重み付けラウンドロビン
• 複数値（Multi-value）回答

「コンスタントな」機構

• コンスタントじゃない機構
  • データベース障害 -> 待機系へフェールオーバー
  • データセンター障害 -> リモートのDCへ
  • 依存関係の障害 -> ロールバック
  • APIの仕様変更
  • ストレージ障害 -> バックアップからのリストア
• アンチパターン
  • テストしない うまくいくか、または、そうならないか
  • 99.99% のケースに最適化
    • もし 0.01% が起きたら、そのときはプラン Y を実行しよう
  • 顧客からの「無制限」要求
    • 絞るか、早く失敗させる
• Route 53 DNS API
  • ListResourceRecordSets はページネーションする
  • APIコール数はスロットルされる
  • API 過剰コールの場合は早急に失敗させる
  • 継続的なサービス提供のための上限

「コンスタントな」機構のために

• 全ての操作は上限のあるワークロードである
• 通常は少ない稼働 / たまに高稼働
  • 「ほとんどだが全てではない」ワークロードの最適化は慎重に
  • キャッシュも慎重に
• API はスロットルしよう

所感

これまで「Route 53 の SLA が 100% といっても、DNS はクライアント側のキャッシュがあるしなー」と軽く考えていたんですが、そういう簡単な話ではなかったです。なぜ 100% を目指さざるを得ず、そのために何をしているのか。通常クラウドインフラは「落ちてもリカバリしてなんぼ」という先入観がありましたが、Route 53 にはその考え方をしていないということがよく分かったセッションでした。